1. Field of the Invention
This invention relates to data networks and, more specifically, to sharing resources among data flows in a data network.
2. Background Information
A data network is a geographically distributed collection of nodes interconnected is by communication links and segments for transporting data between end nodes, such as personal computers and workstations. Many types of network segments are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, typically connect large numbers of geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines. The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between nodes on various networks. The nodes typically communicate over the network by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). In this context, a protocol consists of a set of rules defining how the nodes interact with each other.
In a typical arrangement, end nodes in a data network are coupled via one or more intermediate nodes, such as routers. Routers are often configured to “route” data, such as packets, between various nodes in the network. Routing is typically performed at layer-3 (L3), which is the network layer of the Open Systems Interconnect Reference Model (OSI-RM). Routers often maintain forwarding databases (FDBs), which are typically configured to hold routing information including L3 addresses and interface information that the router uses to determine where data (e.g., data packets) are to be forwarded in order to reach their destination. For example, a router may have a routing database containing one or more entries wherein each entry contains a L3 destination address of a destination node and interface information about an interface on the router through which the destination node may be reached. A data packet containing a destination address that matches a destination address of an entry in the routing table is forwarded by the router to the interface specified by the matching entry for transfer to the destination node.
A router may execute one or more routing protocols that enable the router to route packets and exchange routing information with other routers in the network. The routers often use this information to configure (e.g., compute) their FDBs. The routing protocols may include distance-vector protocols, such as the Routing Information Protocol (RIP), or link-state protocols, such as the Intermediate-System-to-Intermediate-System (IS-IS) protocol or the Open Shortest Path First (OSPF) protocol. Routing information is typically exchanged between the routers in the form of advertisement messages. For example, nodes executing the IS-IS protocol exchange information using an advertisement message called a Link State Packet (LSP). Likewise, nodes executing the OSPF protocol exchange routing information using an advertisement message called a Link State Advertisement (LSA). As used herein, an advertisement message refers generically to a message that a routing protocol uses to convey routing information to other intermediate nodes (e.g., a router, a switch) in the network. An intermediate node that acquires an advertisement message may use information contained therein to update its FDB.
Data networks are increasingly being used to transport many forms of information including voice and video information. Voice information may be carried by various technologies including Voice over IP (VoIP). VoIP refers to a group of technologies that may be used to transmit voice information over data networks from a source (calling party) to a destination (called party). Such networks may include a plurality of voice agents that convert voice information from its traditional telephony form to a form that is suitable for packet transmission. In other words, the voice agent encodes, compresses and encapsulates the voice information into a plurality of data packets. Examples of voice agents include IP telephones, VoIP gateways, certain private branch exchanges (PBXs), personal computers (PCs) running communication applications, network devices providing voice gateway services, etc. A calling party uses a voice agent to initiate a VoIP call. Once the voice information has been converted into packet format, it is carried by the computer network to a second voice agent configured to serve the called party.
Similarly, video information may be carried by various technologies that include video conferencing. Here, voice and video information may be processed much like voice information is processed in VoIP systems. That is, voice and video information may be converted by a voice and video agent at a calling party which encodes, compresses and encapsulates the voice and video information into data packets and transfers the packets via a data network to a video agent at the called party. The called party's video agent may unencapsulate, uncompress and decode the data packets to produce the voice and video information and present this information to the called party, accordingly.
Voice and video agents may employ a “transcoder” to convert data coded using a particular coding stream into data that is coded according to a different coding scheme. For example, a transcoder may be used to convert voice data coded by a first codec (coder/decoder) that employs a particular coding/decoding scheme to voice data that may be decoded by a second codec that employs a different coding/decoding scheme. Transcoding data often changes the network bandwidth requirements associated with carrying the data. For example, the voice data coded by the first codec above may be carried on a data link with a bandwidth of 700 Kilobits-per-second (Kbps). The same voice data transcoded by the transcoder may be carried on a data link that has less bandwidth (e.g., 300 Kbps) due to, e.g., data compression introduced by the transcoder.
Voice and/or video information, unlike static data files or records, is highly sensitive to delayed and lost packets. That is, delays in receiving data packets or the loss of packets may seriously degrade the quality of the information as experienced at the called party's agent. Accordingly, packets carrying this information must be delivered to the called party with a high probability of success and in a timely manner.
Data networks typically incorporate various services and resources to mitigate the effects of delayed and lost packets. In particular, an intermediate device in the data network may provide specific resources and/or services that are configured to affect the rate at which traffic moves through the device in an effort to avoid traffic congestion in the network that may lead to lost or delayed traffic. These resources and/or services may include priority queues, filter settings, traffic shapers, queue selection strategies, congestion control algorithms, etc. Depending on the selection or allocation of such resources and services within the network, traffic may be forwarded at different rates and at different priorities in the network in an effort to avoid congestion and ensure timely delivery of the traffic.
Some applications may incorporate unidirectional data flows configured to transfer time-sensitive traffic from a source (sender) in a data network to a destination (receiver) in the network in accordance with a certain “quality of service” (QoS). Here, network resources may be reserved for the unidirectional flow to ensure that the QoS associated with the data flow is maintained. The Resource Reservation Protocol (RSVP) is a network-control protocol that enables applications to reserve resources in order to obtain special QoS for their data flows. RSVP works in conjunction with routing protocols to, e.g., reserve resources for a data flow in a data network in order to establish a level of QoS required by the data flow. RSVP is defined in R. Braden, et al., “Resource ReSerVation Protocol (RSVP),” Request For Comments (RFC) 2205.
Pursuant to RSVP, a data flow is a sequence of messages that have the same source address and same destination address (unicast or multicast). The messages of a flow also typically have the same protocol number and the same source and destination port numbers. A session is a collection of one or more data flows that have the same unicast or multicast destination address. Sessions typically utilize port and protocol numbers much like data flows. Sessions differ from data flows in that a session may have multiple senders, whereas a data flow only originates from a single sender.
In a protocol, such as RSVP, signaling messages are used to establish a reservation of resources to ensure sufficient resources are available for a data flow carrying e.g., time-sensitive data. RSVP defines two fundamental types of signaling messages, a RSVP path (Path) message and a RSVP reservation request (Resv) message.
Typically, Path messages are sent by sources to identify them and indicate, e.g., the bandwidth needed to receive their programming or content. These messages proceed on a path hop-by-hop through the data network to one or more receivers. The Path messages make intermediate devices (nodes) on the path aware of the possibility that a reservation of resources may be required. If a receiver is interested in the programming or content offered by a particular source, it responds with a RSVP Resv message to reserve the resources for a data flow between the sender and receiver. The Resv message travels hop-by-hop on the same path back to the source. At each hop, the corresponding intermediate device establishes a reservation for the receiver and sets aside (reserves) sufficient resources to accommodate the data flow between the sender and receiver. These resources are immediately made available to the data flow. If sufficient resources are not available, the reservation is refused explicitly so that the receiver knows it cannot depend on the corresponding resources being devoted to its traffic. By using RSVP, packets carrying, e.g., time-sensitive information can be accorded the resources and services they need to ensure timely delivery.
Resv messages typically include a set of options that are collectively called a reservation “style.” These options are specified in an “option vector” field of the style object that is included in the Resv message. One option, “sharing control,” concerns the treatment of reservations for different senders within the same session. This option can be specified to establish a different reservation for each upstream sender (distinct option) or make a single reservation that is “shared” among all packets of selected senders (shared option). Specifying the shared option enables the new reservation request to share resources that have already been allocated to an existing (prior) reservation. The shared option is typically used for sessions in which multiple data sources are unlikely to transmit simultaneously.
Another reservation option, “sender selection control,” controls the selection of senders to the session. This option can be specified to select senders from a list of “explicit” senders (explicit option) or to select senders using a “wildcard” that implicitly selects all senders to the session (wildcard option). The sharing control together with the sender selection control “imply” (specify) the reservation style associated with the reservation request.
For example, the shared explicit (SE) style is specified by the combination of the shared and explicit options. A SE-style reservation creates a single reservation that is shared among a specific set of senders that are sending data to a given destination. The set (explicit list) of senders is specified using filter spec objects that are included in the Resv message. Likewise, the wildcard-filter (WF) style is specified by the combination of the shared and wildcard options. A WF-style reservation creates a single reservation into which data flows from all upstream senders are mixed. As new senders appear, the reservation is extended to include these new senders.
The sharing control and sender selection control options provide one technique for sharing resources among RSVP sessions. Another technique that can be used to share resources is described in co-pending and commonly assigned U.S. patent application Ser. No. 09/871,108 titled “System Sharing Resources Among RSVP Sessions.” This technique uses a session group identifier (SGID) to enable resource sharing between different RSVP sessions that originate from a common source (sender) of traffic. Sessions that meet certain criteria defined by the technique are associated with a group that is designated by a SGID. Sessions within the same group share the resources that have been reserved for that group.
Specifically, a sourcing entity generates a locally unique resource identifier (ID). The sourcing entity then uses this resource ID when signaling to reserve resources for a first session. The sourcing entity may then decide to have these resources shared with a second session by reusing this same resource ID when signaling to reserve resources associated with the second session. When the second session is being created, intermediate devices are configured to recognize that a reservation associated with this resource ID already exists. The intermediate devices are further configured to share the previously reserved resources between the first and second sessions, rather than reserve additional or further resources for the second session.
One problem with the resource sharing techniques described above is that they require a common element between data flows, such as a common source or a common destination. For example, the SE and WF reservation techniques each require a common destination and the SGID technique requires a common source. Because the techniques require either a common source or common destination, they may not be well suited for scenarios involving, e.g., many different senders (sources) and receivers (destinations).